Entstehung, Aufbau und Funktionsweise des Programmcodes des Teams Projekt 1 für die deutsche Meisterschaft in Magdeburg anhand von Grundideen und konkreter Beispiele

 

 

Allgemeines

Das Ziel des Projektkurses Informatik war die eigenständige Entwicklung eines Roboters, der in einer der „Soccer“-Klassen im Robocup antreten kann. Die verschiedenen Klassen, in denen angetreten werden kann, sind:

    1v1-Open

    1v1-Lightweight

    2v2-Open

    2v2-Lightweight

Unser Team, bestehend aus Jonas Pesch, Julian Ponjezc, Samuel McCartney, Pascal Dettki und mir entschieden uns an der Klasse 1v1-Open Teilzunehmen, in der 1 Roboter (kurz: Bot) pro Team auf einem Feld gegen einen anderen antritt und in einer vorgegebenen Zeit versucht, möglichst viele Tore zu erzielen. Die Regeln, nach denen gespielt sind, sind ähnlich der Regeln beim Fußball, es gibt 2 Halbzeiten mit einer Halbzeitpause, der Gewinner des Spiels ist derjenige mit den meisten erzielten Toren. Das Maximalgewicht des Roboters beträgt 2,5 kg, der maximale Durchmesser beträgt 23 cm.

Die Programmierung ist wichtiger Bestandteil der Entwicklung des Roboters. Hardware und Software müssen zudem aufeinander abgestimmt sein, um einen Bot möglichst effizient fahren zu lassen.

 

Entstehung des Programms und der Taktik

Um eine funktionstüchtige Programmierung für den Roboter zu erstellen, ist die Entwicklung einer Taktik wichtig. Wir entschieden für eine schnelle und möglichst leichte Bauart, die uns taktisch schnellen Ballbesitz und rasche (Rück-)Bewegung in die Verteidigungsposition ermöglichte.

Implementiert wird dies durch Zonen, die abhängig von der Ballrichtung definiert wurden. Die Zonen sind unabhängig von der Ballentfernung gewählt und nur abhängig von der Ballausrichtung zum Roboter.


 

Funktionsweise und Aufbau des Programms

Fahrverhalten (1)

Das Programm beruht auf den Sensorwerten, die der Infrarot-Ring über den I2C-Bus liefert. Die empfangenen Daten werden über Teensy-Prozessoren übertragen, einer gibt die Befehle über das Fahrverhaltens an die Motoren. Die empfangenen Daten des Infrarot-Ringes über die Ballrichtung werden in Gradzahlen von +180 bis -179 umgerechnet.

Um die Taktik zu realisieren und den Ball schnell in Besitz zu bringen, wurden im Zuge der Programmierung Zonen erstellt, die das Fahrverhalten bestimmen. Die Zonen können auch als Ereignisse betrachtet werden, da sie abhängig von der Position des Balles zum Bot eintreten.

Zone 1 tritt beispielsweise ein, wenn der Ball zwischen +15° und -15° liegt. Implementiert wird dies durch:

            if (abs(ballrichtung) <= 15)

Die Betragsfunktion „abs()“ gibt den Absolutwert einer Zahl an, das heißt, wenn die Zahl negativ ist, findet ein Vorzeichenwechsel statt. Die Abfrage stellt also fest, ob der Ball im Bereich -15° bis +15° liegt. Ist dies der Fall, fährt der Roboter ohne Drehung in Richtung der gegnerischen Torwand. Der Ball wird, sofern er sich noch nicht in der Schale befindet, auf dem Weg nach vorn in die Schale gelangen.

Textfeld:  
Abbildung 1

 

 

 

 

 

In dieser Situation würde der Roboter geradeaus auf den Ball zufahren.

 

 

 

 

 

 

 

 

 

Zone 2 wurde von (+/-) 15° bis (+/-) 60° definiert. Dieses Ereignis tritt ein, wenn die folgende Abfrage korrekt ist:

            „if ((abs(ballrichtung) >= 15) && (abs(ballrichtung < 60)))“

Wieder wurde der Befehl „abs()“ verwendet, um das Vorzeichen zu ändern (falls dieses negativ war), und es wirde abgefragt, ob der Ball sich in der definierten Zone befindet.

Ist dies der Fall, wird die Richtung, in die der Roboter fährt berechnet durch:

            „(sign(ballrichtung) * 60)“

 

Der mathematische Befehl „sign“ liefert den Wert -1, wenn die Ballrichtung negativ ist, und +1,  wenn sie positiv ist Die Richtung, in die der Roboter fährt, ist so variabel und abhängig von der Position des Balles.

 

 

Textfeld:  
Abbildung 2

 

 

 

 

 

Der Ball befindet sich ca. im 30° Winkel zum Roboter. Der sign-Befehl liefert also den Wert 1.
Dieser Wert wird mit 60 (die Richtung in die sich der Roboter bewegen soll) multipliziert, wodurch die Fahrtrichtung zustande kommt. Befände der Ball sich auf der Position -30°, führe der Roboter in die Richtung -60°.


 

Zone 3 ist ähnlich der zweiten Zone, sie geht von (+/-) 60° bis (+/-) 90°. Wie in Zone 2 wird dies beschrieben durch:

            if ((abs(ballrichtung) >= 60) && (abs(ballrichtung < 90)))

Auch die Berechnung der Fahrtrichtung ist bis auf die geänderten Werte dieselbe. Schematisch dargestellt sieht diese so aus:

Textfeld:  
Abbildung 3

 

 

 

Wie in Zone 2 fährt der Roboter den größeren der beiden Winkel als Fahrtrichtung.
Dies dient dem Zweck, den Ball „einzufangen“ und gleichzeitig den Roboter hinter den Ball zu bringen.

 

 

 

 

 

 

 

 

 

 

Zone 4 ist für den Fall, dass der Ball schräg hinter dem Roboter befindet. Der Bereich in dem dies zutrifft, ist von (+/-)90° bis (+/-)135°. Der Roboter soll sich gerade und ohne Drehung nach hinten bewegen, damit er schnell hinter den Ball kommt, um schnell erneut einen Angriff zu starten zu können.

Die dazugehörige Abfrage ist:

            „if ((abs(ballrichtung) >= 90) && abs(ballrichtung < 135))“

Textfeld:  
Abbildung 4

 

 

 

 

Der Ball liegt schräg hinter dem Roboter, folglich ist die Fahrtrichtung (180).

 

 

 

 

 

 

 

 

 

Hier muss die Fahrtrichtung nicht mithilfe des „sign()“ Befehls ausgerechnet werden, da der Roboter in jedem Fall (vorausgesetzt der Ball befindet sich in Zone 4) rückwärts fahren soll.

Die letzte, aber nicht minder wichtige Zone 5, bestimmt das Verhalten für die Situationen, in denen sich der Ball direkt hinter dem Bot befindet. Hier ist zu beachten, dass die Chance auf Eigentore sehr hoch ist, wenn der Roboter sofort nach hinten fährt, er also den Ball ins eigene Tor schieben könnte. Deswegen muss der Roboter dem Ball zunächst ausweichen, bis es sicher rückwärts zu fahren, um Eigentore zu vermeiden. Diese Zone ist definiert von (+/-) 135° bis (+/-) 180 Grad.

Die Zone wird definiert durch die Abfrage:

            if ((abs(ballrichtung) >135)

 

Bei der Berechnung der Fahrtrichtung ist zu beachten, dass hier eine Modifikation an der oben (in Zone 2&3) verwendeten Rechnung vorgenommen werden muss. Dies rührt daher, dass die oben verwendete Rechnung darauf abzielt, in Richtung des Balls zu fahren. Dies wäre hier jedoch kontraproduktiv, da man diesen umfahren will und dabei ohne weiteres Zurückrollen des Balles hinter ihn gelangen will, ohne diesen weiter in Richtung (eigenes) Tor zu bewegen. Deshalb wird um die Fahrtrichtung sinnvoll zu ermitteln vor den „sign()“-Befehl ein „-“ gesetzt, damit der Roboter in die entgegengesetzte Richtung fährt.

Die Fahrtrichtung ergibt sich also aus der Rechnung:

            „(-sign(ballrichtung) * 150)“

Textfeld:  
Abbildung 5

 

 

 

 

Der Ball liegt bei ca. 155°. Die Fahrtrichtung ist also folglich (-(1)*150)=-150.

So wird ermöglicht, dass der Roboter am Ball vorbeifährt ohne diesen weiter in die eigene Hälfte zu bewegen.














Beispiele

Das Fahrverhalten und die Strategie kann nun leicht anhand der Zonen erläutert werden. Angenommen der Ball liegt etwa 30 cm rechts-hinter dem Roboter, also in Zone 5. Der Roboter fährt folglich mit der Fahrtrichtung -150° los (siehe Abb. 5), bis sich der Ball in Zone 4, also im Bereich einer Ballrichtung<135° befindet. Der Bot fährt nun, nachdem er an dem Ball schräg vorbei gefahren ist, gerade nach hinten (siehe Abb. 4), bis die Ballrichtung kleiner als 90° beträgt und sich somit der Roboter in Zone 3 befindet. Wie in Abb. 3 skizziert fährt der Roboter nun mit einer Fahrtrichtung von 90° auf dem Ball zu. Die Ballrichtung verringert sich immer weiter und kurzzeitig befindet sich der Ball in Zone 2, der Winkel der Fahrtrichtung verringert sich also und der Ball wird wie in Abb. 2 dargestellt angesteuert. Sobald sich der Ball in Zone 1 befindet, beginnt die gerade Fahrt nach vorne.

 

Fahrverhalten (2) - Eckenprogramm

Bei der oben beschriebenen Taktik fährt der Roboter, sobald er denn Ball „vor sich sieht“, sofort auf das gegnerische Tor zu. Dies führt im besten Fall zu einem Tor, denn der Bot könnte mit dem Ball das Tor des Gegners treffen. Da das Tor jedoch nur etwa 1/3 der Rückwand des Gegners einnimmt, gehen viele Torchancen verloren. Hier kommt das Eckenprogramm ins Spiel. Dieses zählt, sobald der Ball sich in der ersten Zone befindet, hoch. Dies geschieht mithilfe der „ElapsedMillis“ also Millisekunden. Bleibt der Ball für die gegebene Zeit in Zone 1 ist es wahrscheinlich, dass der Roboter das Ende des Spielfeldes erreicht hat. Nach 2,5 Sekunden beginnt der Roboter zuerst in Richtung 90 zu fahren, also nach rechts. Hat der Roboter also in der linken Ecke gestanden, bewegt er sich nun in Richtung Tor, in welches er nun den Ball schieben kann. Nach weiteren 2,5 Sekunden beendet er seine Bewegung nach rechts und beginnt sich in Richtung (-90) zu bewegen, also nach links. Stand der Roboter vorher nicht in der linken, sondern in der rechten Ecke, fährt dieser zuerst 2,5 Sekunden gegen die Wand, um dann die Richtung zu ändern und in Richtung Tor zu fahren.

 

Aufgetretene Probleme

Im Laufe des Wettbewerbs stießen wir auf verschiedene Probleme bezüglich der Programmierung. Ein Motor „schwächelte“, aus diesem Grund fügten wir einen Ausgleichswert in die Drehrichtung ein, um die Entstehende Drehung zu kompensieren. Zudem rief das Eckenprogramm das Problem hervor, dass der Roboter beim Start des Programms nach links fuhr, was behoben wurde in dem der Timer bei jedem Start „genullt“ wurde.

Da wir vor dem Wettbewerb auf niedrigerer Motorleistung gefahren sind, mussten wir zudem die Zonen anpassen, da durch die hohe Geschwindigkeit die Richtungswechsel nicht mehr möglich waren. Die Zonen wurden also im Programm vergrößert, um trotz langsamerer Richtungswechsel den Ball trotzdem noch zu treffen und ins Tor zu bringen.

 

            Felix Schönwasser